Electronic patient monitoring system

ABSTRACT

An electronic patient monitoring system comprising a monitoring client module configured to receive real time data from monitoring devices connected to a patient, and historical information pertaining to the patient&#39;s physical characteristics, past medical history, current medications, drug allergies, among other information; the monitoring client capable of processing this information to determine whether a treatment ordered by a health care provider is appropriate under the circumstances. The monitoring client module may communicate with a communications module having a user interface, through which orders, such as medication orders, may be entered and transmitted to the monitoring client module. The monitoring client module, in turn, may transmit warnings or recommendations to the communications module for review by the provider. The original order may be confirmed by the provider, or a modified order may be entered in the communications module, which may then be transmitted to the monitoring client module for further processing of the order.

BACKGROUND

The present invention relates to systems and methods to provideelectronic intermediation among medical devices delivering treatments topatients, medical devices monitoring parameters associated with thosepatients, and health care providers who order, process or initiate thosetreatments. An object of the invention is to reduce the incidence ofmedical treatment errors, and to improve the efficiency of tracking apatient's course of treatment.

Despite the existence of systems incorporating electronic medicalrecords (“EMR”), and computerized provider order entry (“CPOE”), theprocess of ordering and delivering medical treatments still has thepotential to cause critical information to be miscommunicated, to allowtreatment decisions to be made without ready access to completeinformation, and to delay implementation of treatment orders due tounnecessarily redundant and inefficient procedures. An approach todealing with this problem is illustrated herein by using medicationordering as an example. It should be noted, however, that the inventionas described herein can be applied to other treatment or diagnosticdecisions involving the care of a patient.

Medication errors may be responsible for over 300 deaths and may injureover one million people each year in the United States. Hospitals underfinancial stress may experience an increased incidence of medicationerrors. Medications associated with the most dangerous errors includeinsulin, narcotics, heparin and chemotherapy. Sources of error includeadministering the wrong drug, the wrong concentration of drug, at thewrong rate, or via the wrong route (medications can be administeredorally, intravenously, intramuscularly, subcutaneously, rectally,topically to the skin, eye or ear, intrathecally, intraperitoneally oreven intravesically). Even with proper orders and proper labeling,medications still can be administered improperly because of illegiblehandwriting, miscommunication of orders, and mispronunciation of drugshaving similar names. The trend toward the use of electronic medicalrecords (EMR), and bar coding systems for medications has been shown toreduce the incidence of medication errors. EMR systems, for example, canfacilitate computerized provider order entry (CPOE), and flag orders fordrugs that do not match a patient's characteristics such as diagnosis,allergies, weight or age. However, these systems have not been widelyadopted, and their implementation can result in significant delays andinefficiencies in ordering, preparing and administering medications.

It has been estimated that medication infusion devices are involved inup to one third of all medication errors that result in significantharm. The wrong drug may be hung, incorrect parameters (e.g. drugconcentration or rate of infusion) may be entered, or existing infusionparameters may be improperly changed. Of infusion pump-related deaths,nearly half may be due to user error, and most of these may be due toerrors in programming the infusion device.

An effective Monitoring system should monitor and intercede at any phaseof the medication ordering and administration process to help minimizeany of a number of adverse events that could result from the treatment.The medication treatment process conceptually can be separated intothree phases: a prescription phase, a medication preparation phase, andan administration phase. Errors can occur when a prescription is writtenor entered, when a drug is retrieved for use or mixed in solution, orwhen it is administered to the patient. It would be particularlydesirable for a monitoring system to not significantly impair theefficiency with which medications are ordered, prepared or administered,and preferably to actually reduce the time required to perform thoseactivities by collecting, organizing and presenting relevant real-timeinformation to the user.

SUMMARY

In an exemplary embodiment involving the ordering and administration ofmedications, the Electronic Patient Monitoring system may comprise afirst data-gathering module (e.g., a Monitoring Client) and a secondorder-input module (e.g. a fixed or portable communications device)having a user interface for transmitting an order or receivingpatient-related information. The first module may be configured toreceive and store measured parameters pertaining to a patient's currentcondition, such as blood pressure, heart rate, heart rhythm,temperature, oxygenation, respiratory rate, or ventilation, for example.The first module may also be configured to receive information aboutpre-existing parameters related to the patient from a first database(e.g. an EHR database containing information about the patient),including drug allergies or sensitivities, other currently administereddrugs, age, weight, height, kidney or liver function, for example. Thefirst module may also be configured to obtain medication informationabout the ordered medication and/or pre-existing drugs from a seconddatabase (e.g. a drug information database), such as known druginteractions, effects of the medication or pre-existing drugs on bloodpressure, pulse, heart rhythm, or respirations, for example. The firstmodule can be configured to compare the patient's currently measuredparameters and received pre-existing parameters with known normalranges, and create a table of patient parameters found to be outside thenormal ranges. The first module may then compare the table of patientparameters with a table of corresponding parameters obtained from thedrug information database. If a match is found to exist between thetable of patient parameters and the table of corresponding parameters,the first module may then retrieve one or more pre-entered and storedmessages for transmission to the second (order input) module. Thesemessages may include, for example, warnings to a user of the secondmodule that are appropriate for the particular medication ordered, thepatient's pre-existing drugs, and the patient's current and pre-existingmedical condition. Optionally, further repetitions of warnings may beavoided once a warning has been received by the second module, and thewarning has been acknowledged by the user of the second module throughan input signal from the user interface.

In other embodiments, the Electronic Patient Monitoring system mayprovide the user with editable default values derived from standarddosing and administration guidelines obtained from the drug informationdatabase, and can alert the user to modifications that may be indicatedbased on the patient's current and pre-existing medical condition,allergies or other existing drugs. The Monitoring system preferablyminimizes the amount of typed input required of a user.

In other embodiments, the first module or other modules of theElectronic Patient Monitoring system may also be used to identifyordered medications to be delivered to the patient's bedside (throughthe use of, for example, bar codes and readers or RFID tags andscanners), and verify that the appropriate medication and dosage arebeing prepared and delivered to the patient. In an embodiment, the firstmodule may also interact either in a hard-wired or wireless fashion witha device that administers treatment, such as a solution/medicationinfusion pump. In the case of an infusion pump, the first module oranother connected module may provide the pump with infusion settingssuch as flow rate or infusion pressure, and receive from it variousstate parameters such as, for example, the presence of air in theinfusion line, the amount of solution remaining in an IV bag to which itis connected, or the pressure of fluid in the infusion line. If theparameters are found to be abnormal, the first module may be configuredto respond by signaling the pump to halt infusion, alter the rate ofinfusion, and/or alert a health care provider or others of theabnormality, either directly through an alarm incorporated in the firstmodule, or by transmission of an alarm to the second module. In afurther embodiment, the first module may also be configured tocommunicate with various medical devices used to monitor a patient'scondition, such as, for example, blood pressure monitors, ECG monitors,pulse oximetry monitors, temperature monitors, and the like. In somecases, the first module can be programmed to emit an alert to thepatient or other persons if the monitored parameters fall outside apre-determined range. In some embodiments, the first module can transmita signal to a monitoring device to conduct an unscheduled measurement bythe device. The first module may communicate with various health careproviders at various locations, and in an embodiment may be able tonotify the patient to whom it is assigned of an abnormality, andrecommend corrective action through, for example an audible alert orrecorded message.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic representation of an exemplary Electronic PatientMonitoring system, showing paths of communication among systemcomponents.

FIG. 2 is an illustration of a display screen on a health careprovider's portable communications device, showing a list of patientswhose information the provider can access.

FIG. 3 is an illustration of a display screen on a health careprovider's portable communications device, showing devices associatedwith a particular patient, with current data from the devices andone-touch access to some of the patient's medical information.

FIG. 4 is an illustration of a display screen on a health careprovider's portable communications device, showing data entry fields fora prescription for a medication for use with an intravenous infusionpump.

FIG. 5 is an illustration of a display screen on a health careprovider's portable communications device, showing a risk profileassociated with an ordered medication, and a suggested course of action,as generated by the Monitoring.

FIG. 6 is an illustration of a display screen on a health careprovider's portable communications device, showing a medicationprescription ready for submission by the ordering provider.

FIG. 7 is an illustration of a display screen on a health careprovider's portable communications device, showing how the Monitoringsystem can display confirmation to the ordering provider that theprescription has been transmitted to the pharmacist.

DETAILED DESCRIPTION

As shown in FIG. 1, components of the Electronic Patient MonitoringSystem may include one or more Monitoring Clients 1,4, each of which maybe assigned and in physical proximity to an individual patient 2, and amore remote Monitoring Server 3 for the uploading of information from anumber of Monitoring Clients 1,4, and for downloading information andinstructions from various sources to the Monitoring Clients 1,4. When inthe patient's room, a health care provider can interact directly with aMonitoring Client 1 to obtain information about the patient 2 or toenter orders pertaining to the patient 2. Alternatively, providers atremote locations (e.g., doctor's office, nursing station 5, hospitalpharmacy 6) may interact with an individual Monitoring Client 1 througha communications link with the Monitoring Server 3, or directly via ahospital local area network having each Monitoring Client 1,4 as a node.

In an embodiment, each Monitoring Client 1 is assigned to a specificpatient 2, and can be a desk-based, portable or hand-held controllerwith display and user input capability. Preferably, it is portable andallows for efficient data viewing and data entry, such as a notebook PC,netbook PC, tablet PC, or even a ‘smart-phone,’ with or without touchscreen capability. The designation of a particular Monitoring Client 1to a particular patient 2 may be made using any of a number of methods,including (but not limited to) a unique patient identifier using a barcoded or RFID tag-embedded wrist band, for example. The MonitoringClient 1 may include one or more microprocessors to send and receiveinformation relevant to the patient's care or condition. In someembodiments, the Monitoring Client 1 may be physically associated with amedical infusion pump 7 either permanently or detachably. This can beaccomplished by a docking interface between the two devices. TheMonitoring Client 1 can communicate with the pump 7 in a number of ways,including, for example, through electrical contacts in the dockinginterface, by means of an electrical connector, or wirelessly by meansof transceivers on each device. The Monitoring Client 1 can alsocommunicate with other databases in the facility 8, with databasesexternal to the facility 9,10, and with health care providers viaportable communications devices 11 (including, for example, physicians,nurses, and pharmacists). This can be accomplished by a wired connectionto a facility server through a connector in the patient's room (such as,for example, a Category 5 local area network connector), or wirelessly12. In one embodiment, access to intra and extra facility databases ismediated 13 through the Monitoring Server 3, which can then centralizethe software and application programming interfaces required tocommunicate with databases having disparate organization, formatting andcommunications protocols. Thus, in an embodiment, any software updatesmay be largely limited to the Monitoring Server 3, reducing themaintenance requirements on the individual Monitoring Clients 1,4.Optionally, a Monitoring Client 1 can communicate with medical treatmentdevices such as infusion pumps 7 to receive information about theprogress of treatment, and to provide operational instructions to thetreatment device. In another embodiment, the Monitoring Client 1 mayalso communicate with medical diagnostic or monitoring devices (such as,for example, an electrocardiographic (ECG) monitor 14, a blood pressure(BP) monitor 15, a pulse oximeter or CO2 capnometer 16, or other devicessuch as temperature monitors, etc.) to receive readout information fromthe devices, and potentially to instruct 18 the devices to take areading when desired by a provider or by algorithm.

In an embodiment, the Monitoring Client 1 has the ability to communicateand interact directly with a health care provider using a hand-held orportable communications device 11. This may be conveniently accomplishedwirelessly 12, so that communications can be maintained regardless ofthe patient's location in the facility, or the provider's locationeither within or outside the facility. In one aspect, informationspecific to the patient 2 can be stored locally in the Monitoring Client1, so that the patient's health care provider can access the informationdirectly without having to access the Monitoring Server 3. Byincorporating appropriate safety and security clearances, changes to thesettings or flow parameters of a connected infusion pump 7 or monitoringdevice 14-17 can be accomplished directly between a provider'scommunications device 11 and the Monitoring Client 1, with selectedchanges being also communicated to Monitoring Server 3, and thence toother appropriate locations, such as the Nursing Station 5, and/orPharmacy 6. Furthermore, any new order pertaining to the patient 2 maybe entered in the ordering provider's communications device 11 andtransmitted to the Monitoring Client 1, which in turn can then notifythe care giver (e.g. RN) via the care giver's own portablecommunications device 11. Preferably, any information acquired andstored in the Monitoring Client 1 is periodically uploaded to theMonitoring Server 3 and stored in a patient-specific database. Thus, ifa patient's Monitoring Client 1 needs to be taken out of service, a newdevice can be assigned to the patient 2 and quickly re-populated withthe patient's current information from the Monitoring Server 3. Orders,medications, progress notes, monitoring and treatment data from thepatient's attached devices may also be uploaded from the MonitoringClient 1 to the patient's EHR 19, 19′ for permanent storage.

The Monitoring Server 3 may comprise a computer that can communicatewith and provide some elements of control for a number of MonitoringClients 4 in the facility. It may provide a Monitoring Clients 1, 4 withdata extracted from a number of databases both within 8 and outside 9 ofthe facility. In an embodiment, the Monitoring Server 3 can interrogatethe facility's EHR system 19 for targeted information pertaining to apatient 2, and then populate that patient's Monitoring Client 1 with apre-defined set of information (such as, for example, the patient's age,height, weight, categories of diagnoses, current medications andmedication categories, medication allergies and sensitivities, etc.).The Monitoring Server 3 may establish a link to EHR 19, Laboratory 20,Radiology 21, Pharmacy 22 and other systems (such as, e.g., Cardiology23 or Scheduling database 24) in the facility when, for example, aMonitoring Client 1 has been assigned to a patient 2. With a uniquepatient identifier, the Monitoring Server 3 can obtain electronic access(permission) to receive and send patient-specific data from and to thesesystems. A pre-determined (but selectable) subset of the data may bedownloadable into the Monitoring Client 1 memory. The information thusacquired can then serve as a key database against which new orders canbe analyzed. Orders entered into a Monitoring Client 1 can be checkedfor compatibility with the patient-specific information obtained by theMonitoring Server 3. Optionally, for safety redundancy, orders enteredremotely from a portable communications device 11 can be intercepted bythe Monitoring Server 3 and similarly can be checked. The MonitoringServer 3 may also obtain information from medication databases residingin the facility's pharmacy 22 or externally 9 to determine whether a newpatient order may generate an incompatibility with a patient's existingmedications, for example. In an embodiment, the Monitoring Server 3 maybe programmed to access publicly available internet sites 25 todetermine whether new information pertaining to the patient's orderedmedication should be downloaded and transmitted 13 in an alert to thepatient's health care provider(s). The Monitoring Server 3 may alsoroute information between remote portable communications devices 11 anda patient's Monitoring Client 1.

In an embodiment, the patient's physician, nurse or pharmacist may haveaccess to the patient's Monitoring Client 1 to relay or receive neworders (such as medication orders, for example) pertaining to thepatient 2. The Monitoring Client 1 or Server 3 may then log the neworder and relay the request to the pharmacist 6, and the patient's nursevia the nurse's portable communications device 11 and/or via a fixedterminal at the nursing station 5. A ‘smart phone’ having a customizedcommunications application with Monitoring Client 1 (such as, e.g., aGoogle Nexus One phone or Apple i-phone, among others) may serve as aconvenient portable communications device 11 for providers who are notat a fixed location (such as at an office or remote nursing station). Atablet PC, netbook, or laptop computer may also serve as a convenientportable communications device 11 for both portable and fixed locations.A PC may act as a convenient communication device 11 for fixed ordesktop locations. If a provider is located in the patient's room, he orshe may enter or receive information pertaining to the patient 2 using adirect input through a keyboard or touch screen on the Monitoring Client1.

Example of Monitoring-Assisted Order Entry

The functionality of the Patient Monitoring system can be illustrated byan example in which an ordering provider enters a new medicationprescription for a patient. In this scenario, the physician may view hislist of admitted patients on his hand-held device after entering theappropriate security pass code. In this example, the physician'spatients can be listed as shown in FIG. 2, with limited anduser-selectable information 26 on each patient, such as, for example,age, diagnosis, and medical record number. Alert symbols 27 may betransmitted by the Monitoring Client 1 to the physician's device 11 if,for example, orders for the patient 2 are incomplete, the nurse hasflagged the patient for attention, or if the Monitoring Client 1 hasreceived input from a database or a patient monitoring device 14-17 thathas exceeded a pre-determined threshold for physician notification.

After the physician selects a patient for further review, a display suchas that shown in FIG. 3 may be transmitted to the physician's device 11.The physician can view user-selectable data originating from monitors14-17 to which the patient is connected, and the physician may haveone-touch access to a number of databases 19-21, 23 containingpatient-specific information. In an embodiment, the Monitoring Client 1may be connected or docked to an infusion pump 7 available for use withthe patient 2. In a scenario illustrated in FIG. 3, the physician canpress on the icon representing the infusion pump 7 to order anintravenous medication for the patient 2.

FIG. 4 shows one of a number of possible prescription ordering screenswith which a physician can remotely order a medication. In the exampleillustrated, the physician enters the drug IV Nitroglycerin 28, whichmay be entered by typing or via a drop-down screen populated by thehospital pharmacy's formulary 22, accessed by the Monitoring Client 1via the Monitoring Server 3. The ‘PDR’ button 29 may represent thephysician's one-touch access to an in-hospital 22 or proprietary drugdatabase 9 for detailed drug information. The physician can order thedose of medication, either directly or by accepting a default standardstarting dose 30 provided by the Monitoring Client 1 via the MonitoringServer 3. The physician may also specify the maximum fluid infusion rate31 for the infusion pump 7, in order to assist the pharmacist inpreparing the proper concentration of the drug in a bag for infusion.

FIG. 5 shows an example of how the Patient Monitoring system can detecta risk of an adverse reaction after the physician has entered theprescription. The Monitoring Client 1 can compare the new medication 28to the patient's existing medications and drug allergy list downloadedfrom the EHR 19. The Monitoring Server 3 preferably will have populatedthe appropriate patient-specific data into the Monitoring Client 1, andthe Client 1 will be programmed to look up this information after thenew medication order has been entered. The Monitoring Client 1 may beprogrammed to request a listing of significant adverse reactions anddrug interactions associated with each of the patient's medications andthe new medication 28 from the Monitoring Server 3. The Server 3, inturn can access a pharmacy database 22 or external database 9 for thisinformation. If a potential drug interaction or adverse reaction commonto an existing medication and the new medication 28 are detected, theMonitoring Client 1 may issue a warning 32 and transmit it to theordering physician, as shown in FIG. 5. If the potential adversereaction is due to an effect common to both the new medication and anexisting medication, the Monitoring Client 1 may categorize this as apotentially additive adverse effect and issue a recommendation 33 toreduce the initial drug dose, for example, by 50%.

As shown in FIG. 6, the ordering physician has the option either toaccept the recommendation 33 or edit the recommended dose to anothervalue. In any event, the Monitoring Client 1 may generate and log areport 34 of the warning 32 and any corrective action 33, if any, takenby the physician, with the option for the physician to further edit thereport before logging and entry into the patient's EHR 19.

Once the medication dosing is finally determined, the Monitoring Client1 can forward the order to the communication devices of both thehospital pharmacist 6 and the patient's nurse 5. A report of theaccomplishment of this task may then be transmitted back to the orderingphysician 11, as shown in FIG. 7. The pharmacist can use the informationprovided by the ordering physician to mix an appropriate concentrationof the medication in a solution bag. Both the medication vial and thesolution bag may have identification tags, such as, e.g., bar codeidentifiers, that can be read into the pharmacist's communicationsdevice 6, and which can be verified as correct by the Monitoring Client1 (using the pharmacy database 22 as accessed by the Monitoring Server3). The pharmacist may then generate a unique identification label, suchas a bar code label, to be permanently affixed to the medication bag,the code now being linked uniquely to the patient 2 for whom themedication 28 has been prepared. The identifying code on the label maybe transmitted to the Monitoring Client 1 for later reconciliation whenthe nurse is about to administer the medication 28.

After the prepared medication 28 arrives to the patient's floor, thenurse can then prepare to administer it to the patient 2. In thisexemplary scenario, the Monitoring Client 1 may include an input devicesuch as a bar code reader, which the nurse can use to verify that theidentifying code on the medication bag matches the identity of thepatient 2 for whom it has been prescribed. If the identification matchesthe information entered into the Monitoring Client 1 by the pharmacist,the nurse may be cleared by the device 1 to hang the medication bag andinitiate the infusion via the infusion pump 7. In an embodiment, theMonitoring Client 1 displays to the nurse the prescription, includingthe dose, the maximum fluid rate for the patient, the concentration ofthe drug in the bag, and the infusion rate for the pump (which canoptionally be calculated by a processor in the Monitoring Client 1).With this information, the nurse has the ability to manually calculateand verify that the infusion rate set by the Monitoring Client 1 for thepump 7 is correct.

Network Connectivity Among System Components and Devices

A Monitoring Client device 1 can receive, process, and transmitinformation about a specific patient 2 to which it has been assigned ordesignated. The Monitoring Client 1 can most conveniently be attachableor dockable to an infusion pump 7, bed, or other device to which thepatient 2 may be connected. The Monitoring Client 1 can be a hand-helddevice about the size of a wireless phone or tablet-style netbook, forexample. Conveniently, it may have a touch-screen interface for use bythe patient's provider. It may also be capable of providing output to alarger stationary display screen in the patient's room or at a nursingstation 5 or other convenient location, either through a wired orwireless connection. Each Monitoring Client 1 may communicate with acentral Monitoring Server 3, through which it can access patient datafrom the facility's EHR database 19, Laboratory database 20, Radiologydatabase 21, Pharmacy database 22, or other databases in various otherfacility departments. In some cases, the Monitoring Client 1 can uploadinformation it receives from patient monitoring systems 15-17 or fromprovider inputs to the patient's EHR 19 via the Monitoring Server 3.Monitoring Clients 1,4 may also receive information from databasesoutside of the facility through a Monitoring Server 3 having an internetconnection 25. Various external databases 9 may thus be accessible,including various drug information databases and alert networks dealingwith adverse medication-related events. The Monitoring Server 3 could bearranged, for example, to manage various levels of external databaseinformation helpful in keeping the Monitoring Client 1 contents asup-to-date as possible. This can be accomplished, for example, bycomparing safety and drug information related to the patient as itbecomes available, and prioritizing for updates/downloads on a datatransfer schedule. The Monitoring Clients 1,4 may also communicateeither directly or through the Monitoring Server 3 with portablecommunications devices 11 used by health care providers such as nurses,physicians and pharmacists. In some cases, these devices can have wiredconnections to the Monitoring Server 3 (if used, for example, in fixedlocations such as hospital pharmacies or nursing stations). In othercases, a portable communications device 11 may communicate with theMonitoring Server 3 through VPN-based internet connections using acomputer and a wired or wireless (such as, e.g., Blutooth or WiFi802.11) connection 13 with the device 11. Alternatively, a hand-helddevice 11 (such as a wireless smart-phone or tablet netbook) maycommunicate directly 12 with the facility's Monitoring Client 1 via acellular telephone network.

The communications link between the Monitoring Clients 1,4 and theMonitoring Server 3 may exist via a Category-5 wired network if widelyavailable in the facility, or via wireless transmission using one of anumber of standards, linking all the patient-specific Monitoring Clients1,4 with the central Monitoring Server 3. The server 3 may then serve asa relay for communications with other facility servers 8, with web-basedservers 25, and with inside and outside portable communications devices11 carried by medical care providers. A wireless network provides theadditional functionality of being able to communicate with theMonitoring Server 3 no matter where in the facility the patient 2 maybe.

One method of blanketing an entire facility with wireless coverageinvolves having the facility obtain a license for a private cell-phonenetwork. It may obtain or lease one or more micro-cellular frequenciesto provide for a local communications network throughout the facility.This arrangement can preserve communications when patients and theirMonitoring Clients 1,4 are moved from one location to another within thefacility, maintaining communications with a Monitoring Server 3, variousin-hospital and out-of-hospital databases 8,25, and users at fixedstations 5,6 or with mobile smart-phone, laptop or tablet-type devices11 either inside or outside the hospital. An advantage of this type ofsystem is the level of security provided by a licensed cellularcommunications infrastructure. In addition, an active wireless systemcan monitor the intensity of use in an area and direct additionalchannel frequencies to that area as needed. However, the bandwidthcapacity of the network may not allow for efficient transmission oflarge data files, such as those containing radiology images, forexample.

Alternatively or additionally, a hospital may implement an interne orintranet based communications system, in which an 802.11 WiFi-typeprotocol is used for wireless communications between individualMonitoring Clients 1,4 and the main Monitoring Server 3. To ensureadequate signal reception throughout the facility, a broadband antennamay be mounted on the roof of the building to collect cell phone signalsfrom local wireless phone companies. A fiber-optic or cable network maythen distribute the signals throughout the facility. Alternatively, theMonitoring Server 3 may use the private cell-phone network mentionedabove. Although this system may not be as secure as a micro-cell system,it may be capable of providing the data throughput to accommodate largefiles, such as, for example, radiology images stored in the Radiologydatabase 21. Home or office-based users may be able to connect to thehospital server through VPN access using wired or fiber-optic cable, ora DSL phone line. Data encryption may be used to provide needed patientdata security. In some applications it may be advantageous to implementan asymmetric bandwidth communications network in order to optimizeinfrastructure capabilities. An example of this would be using licensedcellular frequencies in the “upstream” direction from the MonitoringClient 1 to the Monitoring Server 3 and the unlicensed 802.11 WiFifrequencies in the “downstream” direction from the Monitoring Server 3to the Monitoring Client 1. In this example the upstream bandwidth anddata rate requirements are relatively small compared to the downstreamrequirements. In low priority upstream transmissions the MonitoringClient 1 may allow data to be sent over a more distributed andcost-efficient network, such as, for example, a ZigBee network.

Communications between various monitoring devices and the MonitoringClient 1 may be achieved in a cost effective manner using, for example,a ZigBee wireless mesh network. Exemplary monitoring devices include ECGmonitors 14, blood pressure monitors 15, pulse oximeters/capnometers 16,thermometers, and weight scales, among others. A common characteristicof most of these devices is that they provide periodic readouts of asingle or small number of parameters. An intra-hospital devicecommunications system such as the wireless mesh network provides forlow-power digital radio connectivity among devices, and may employ awidely available, license-free 2.4 GHz frequency band. High-levelcommunications protocols may be employed to ensure data fidelity andsecurity. It is highly scalable, allowing hundreds or thousands ofdevices to be used on a single self-forming, self-healing mesh network.Devices connected to the network may communicate with one another andserve as repeaters to transfer data efficiently. The advantages of thissystem are its relatively low cost, scalability and mobility for thepatient being monitored. The wireless range for devices linked to thewireless mesh network can approach 70 meters from each node of thesystem inside a facility. A similar network may be used in providing awireless link within the facility between portable communicationsdevices 11 carried by health care providers and their assigned patientsthrough the patients' Monitoring Clients 1,4.

In many cases, the information being transmitted to the Monitoringclient 1 may include a single parameter value (such as, for example,blood pressure) and a time stamp. The Monitoring Client 1 can beprogrammed to determine whether the value is outside a predeterminedrange, record the value in the patient's EHR 19, and notify theappropriate care-giver via their communications device 11. Furthermore,the network may enable bidirectional communications, and may allow theMonitoring Client 1 to query 15 the monitoring device, instructing it 18to take an unscheduled reading. This can be useful, for example, when anabnormal reading is received, and its authenticity needs to be verified.The Monitoring Client 1 may be programmed to request a repeat reading toverify the abnormal reading. In a further refinement, the MonitoringClient 1 may be programmed to interrupt or adjust the infusion pump 7flow rate, depending on the value of the reading received from amonitoring device 14-17. For example, if the BP monitor 15 indicates ablood pressure below a pre-determined acceptable range, the MonitoringClient 1 may be programmed to instruct the infusion pump 7 to stop theinfusion, and it can transmit an urgent notification 12 to the healthcare provider(s)' communications devices 11. In another embodiment, ifthe infusion pump 7 is capable of measuring the volume of fluid beingdelivered to the patient 2, a processor in the Monitoring Client 1 maytrack the cumulative volume delivered and estimate the amount of fluidremaining in the medication bag. (Alternatively, a processor in theMonitoring Client 1 or infusion pump 7 may calculate the volumedelivered from the infusion rate and elapsed time of infusion). Once theestimated residual volume reaches a pre-determined amount, theMonitoring Client 1 may signal the infusion pump 7 to reduce its flowrate to keep the patient's IV access 35 from running dry. It may alsosend a notification to the nurse's communications device 11,recommending replenishment of the medication or solution.

1. An electronic patient monitoring system comprising: a first moduleconfigured to receive and store information pertaining to a patient,said information including data related to a first parameter of thepatient measured by a device connected to the patient, and data relatedto a second parameter of the patient received from a first databasecontaining information about the patient; and a second module configuredto receive a medication order from a user via a user interfaceassociated with the second module, said second module being furtherconfigured to transmit said treatment order to the first module, whereinsaid first module is further configured to: a) obtain medicationinformation about said medication or other drugs from a second database,the medication information including data providing limitations underwhich such medication is generally administered; b) determine whetherthe medication order must be confirmed by the second module based on themedication information, the value of the first parameter and the valueof the second parameter, and c) transmit a pre-established message fromthe first module to the second module for display on the user interface,said message confirming or warning about the acceptability of saidmedication order.
 2. The electronic patient monitoring system of claim1, wherein the medication information includes drug interactionsinformation, drug allergies information, blood pressure effectsinformation, heart rate effects information, heart rhythm effectsinformation, or respiration effects information, and wherein the firstparameter or the second parameter include data about the patient'scurrently administered drugs, known drug allergies, current bloodpressure, current pulse rate, current heart rhythm, current respiratoryrate or current ventilation.
 3. The electronic patient monitoring systemof claim 2, wherein the pre-established message includes a warning aboutthe potential effects of the ordered medication, said warning includingmeasured data about the first parameter, received data about the secondparameter, or medication information obtained by the first module. 4.The electronic patient monitoring system of claim 3, wherein the firstmodule is configured to generate a signal that the medication order or amodified medication order is to be processed after the pre-establishedmessage has been transmitted and upon receipt of a confirmation signalfrom the second module, the confirmation signal being triggered by aninput signal from the user interface.